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ABSTRACT:  The  Tasmanian  Devil  project  is  a  cooperative  effort  by  the  Defense  Modeling  and  Simulation  Office 
(DMSO),  Air  Force  Research  Laboratory  Warfighter  Training  Research  Division  (AFRL/HEA),  and  USN  Air  Combat 
Environment  Test  and  Evaluation  Facility  (ACETEF)  Aircraft  Simulation  -  Manned  Flight  Simulator  (MFS).  The 
purpose  of  the  project  is  to  gain  experience  in  the  application  of  the  HLA  in  the  distributed  mission  training  domain. 
The  multi-service  federation  development  team  developed  and  demonstrated  two  simple,  parallel  service  federations 
including  aircraft  training  simulators  using  a  common  2vX  air-to-air  training  event.  Each  federation  implemented  a 
common  federation  design  that  was  developed  over  the  course  of  the  project  using  the  Federation  Execution  and 
Development  Process  (FEDEP)  as  a  roadmap.  Specific  project  objectives  include:  1)  implementation  of  HLA 
interfaces  for  the  F-16  and  F-18  simulators,  an  ordnance  server,  and  a  cockpit  radio  simulation;  2)  beta  testing  of 
RTI  NG;  3)  first  use  of  a  VxWorks  version  RTI;  4)  use  of  same  FOM  in  two  federations  with  two  different  mixes  of 
federates;  5)  use  and  assessment  of  agile  FOM  interfaces;  and  6)  examination  of  issues  related  to  an  evolutionary 
and  persistent  federation.  This  paper  describes  the  results  and  lessons  learned  from  the  Tasmanian  Devil  project. 
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1.  Background 

1.1  Introduction 

Tasmanian  Devil  (nicknamed  Taz)  is  a  joint  DMSO, 
AFRL,  ACETEF  MFS  research  project  aimed  at  gaining 
practical  experience  and  insights  in  the  application  of  the 
HLA  in  the  distributed  mission  training  domain.  The 
purpose  of  the  project  is  to  provide  feedback  to  the 
participating  service  organizations,  the  DMSO  technology 
programs,  and  the  larger  M&S  community. 

Specifically,  AFRL  is  interested  in  using  the  HLA  to  meet 
its  future  distributed  mission  training  requirements. 
Together,  AFRL  and  ACETEF  MFS  are  interested  in  how 
HLA  technologies  can  support  joint  training  for  the  full 
range  of  joint  air  combat  missions  and  platforms.  DMSO, 
the  technology  transition  agency  for  M&S  in  DoD, 
developed  the  HLA  and  supporting  tools,  software  and 
processes  to  support  the  broad  DoD  M&S  community. 

Structured  around  the  HLA  FEDEP  [1],  the  Tasmanian 
Devil  research  explores  techniques  for  implementation  of 
HLA  interfaces  for  manned  simulators,  federations  with 
mixed  operating  systems,  embedded  computers,  and 
different  federates,  and,  finally,  issues  related  to 
evolutionary  and  persistent  federations. 

1.2  Some  Definitions 

A  persistent  federation  and  its  accompanying  objective 
FOM  are  defined  as  follows: 

•  A  persistent  federation  is  a  collection  of  specific 
federates  and  an  objective  FOM  used  by  those 
federates.  The  objective  FOM  describes  all  data  that 
might  be  exchanged  at  runtime  by  any  of  the 
federates. 

•  For  any  particular  execution,  any  logical  subset  of  the 
federates  and  the  objective  FOM  may  be  used. 

•  The  federation  is  persistent  because  the  objective 
FOM  and  set  of  federates  are  used  and  reused  over  an 
extended  period  of  time. 

An  evolutionary  federation  is  defined  as  follows: 

•  An  evolutionary  federation  evolves  its  composition 
(FOM  and  federates)  over  time. 

•  The  evolution  must  be  systematically  managed  to 
ensure  that  the  entire  federation  evolves  at  the  same 
pace  and  to  ensure  that  design  decisions  made  early 
in  the  life  of  the  federation  do  not  adversely  impact 
overall  federation  evolution. 


These  terms  are  of  interest  because  it  is  anticipated  that 
future  federations  in  the  distributed  mission  training  will 
be  both  evolutionary  and  persistent. 

FOM  agility  is  defined  as: 

•  FOM  agility  is  the  ability  of  a  federate  to  readily 
participate  in  multiple  federations  that  use  differing 
FOMs. 

FOM  agility  is  of  interest  because,  even  if  the  distributed 
mission  training  community  develops  its  own  persistent, 
evolutionary  federation,  there  will  undoubtedly  be 
requirements  to  interoperate  with  other  federations  in 
other  domains  that  have  different  FOMs  optimized  for 
their  domain.  FOM  agility  may  be  a  mechanism  to 
support  cost-effective  interoperation  with  these  other 
domains.  Further,  FOM  agility  may  also  facilitate  the 
evolution  process,  allowing  federates  to  more  easily  adapt 
to  the  evolving  FOM. 

1.3  Tasmanian  Devil  Project  Objectives 

The  following  key  objectives  were  established  for  the 
Tasmanian  Devil  project: 

•  Demonstrate  use  of  the  HLA  in  a  high  fidelity, 
warfighter-in-the-loop  air-to-air  training  environment 

•  Demonstrate  VxWorks  -based  federates  operating 
with  federates  using  other  operating  systems  and  RTI 
ports 

•  Beta  test  RTI  NG 

•  Implement  native  RTI  interfaces  for  some  federates 1 

•  Gain  HLA  certification  for  the  federates 

•  Demonstrate  use  of  the  same  FOM  in  two  federations 
with  two  different  mixes  of  federates 

•  Use  an  agile  FOM  approach 

•  Assess  agile  FOM  approach 

•  Provide  feedback  on  HLA,  associated  HLA  tools, 
concepts  and  processes 

•  Address  issues  of  evolutionary  persistent  federations 

•  Develop  inputs  for  the  FEDEP  Checklist  [2]  for 
training  federations 

•  Develop  follow-on  plans 

1.4  Research  Approach 

To  accomplish  the  project  objectives  the  team  followed 
the  process  depicted  in  Figure  1.  The  FEDEP  process,  a 
systems  engineering  process  for  the  complete  life-cycle  of 
a  HLA  federation,  was  used  to  guide  the  team  activities. 
The  team  executed  the  FEDEP  process  as  though 
developing  a  real-world  persistent  evolutionary  federation 

1  JSAF  already  had  a  native  HLA  interface  at  project 
start. 
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Figure  1.  Tasmanian  Devil  Research  Approach 


for  the  distributed  mission  training  community,  as 
opposed  to  developing  a  research  prototype.  This  was 
done  so  that,  to  the  extent  possible,  the  team  would 
understand  and  execute  the  process  the  community  would 
ultimately  follow,  and  thereby  make  the  lessons  learned 
applicable  to  that  environment.  Lessons  learned  would  be 
collected  throughout  and  a  period  of  assessment  would  be 
conducted  after  the  FEDEP  was  completed. 

The  project  took  longer  than  anticipated  and  the  red  arrow 
on  Figure  1  shows  the  project  location  in  the  FEDEP  at 
the  time  of  writing  of  this  paper. 

1.5  The  Federations 

Two  prototype  federations  were  developed,  depicted  in 
Figure  2.  The  federations  were  developed  by  the  entire 
team  in  a  combined  execution  of  the  FEDEP,  to  support 
the  same  training  mission,  using  the  same  FOM.  One 
federation  was  integrated  and  operated  at  AFRL  and  was 
designated  Taz-AF.  The  second  was  integrated  and 
operated  at  ACETEF  MFS  and  was  designated  Taz-Nav. 

Taz-AF  included  two  AFRL  F-16  cockpit  simulators  and 
the  AFRL-developed  DMT  Controller  Station  (DCS),  to 
provide  trainer  and  technical  monitor  and  control  of  the 
federation  and  playback  for  after- action  review.  Taz-Nav 
included  two  ACETEF  MFS  F-18  cockpit  simulators  and 


the  ACETEF  MFS-developed  Ordnance  Server  to 
represent  fly-out  of  the  cockpit  missiles. 


Figure  2.  Taz-AF  and  Taz-Nav 


Both  federations  included 

•  JSAF  for  representation  of  threat  aircraft,  SAM  sites 
and  missiles. 

•  JSAF  graphical  user  interface,  providing  a  plan  view 
display  for  the  AWACS  role  player  function. 

•  ASTI  radios  for  communication  between  cockpit 
pilots  and  AWACS  role  player  during  execution  of 
the  scenario,  and  to  communicate  with  technical 
control  during  setup. 


•  ASTI  radios  for  technical  control  and  for  all 
simulation  operators  to  facilitate  technical 
management  of  the  federation. 

•  A  beta  version  of  Virtual  Technologies  Corporation’s 
(VTC)  hlaResults™  tool,  to  collect  and  analyze  data 
and  playback  the  federation  into  the  JSAF  plan  view 
display  for  after-action  review. 2 

1.6  Tasmanian  Devil  Team 

The  Tasmanian  Devil  team  consisted  of 

•  ACETEF  MFS  development  team 

•  AFRL  development  team 

•  ASTi  development  team 

•  Federation  Manager  and  systems  engineering  team 
from  The  MITRE  Corporation,  SAIC,  and  MIT 
Lincoln  Laboratory 

•  RTI NG  support  from  SAIC 

•  Data  collection,  analysis  and  playback  support  from 
VTC 

•  JSAF  Agile  FOM  Interface  support  from  Lockheed 
Martin  Information  Systems 

•  USAF  Aeronautical  Systems  Center  /  Training 
Systems  Product  Group  (ASC/YW) 

•  USAF  Air  Combat  Command  (ACC) 

•  USAF  Air  Force  Agency  for  Modeling  and 
Simulation  (AFAMS) 

1.7  Taz  Schedule 

The  Tasmanian  Devil  project  timelines  were  very  short  - 
approximately  seven  months.  The  ACETEF  MFS,  AFRL 
and  ASTi  development  teams  had  limited  prior 
experience  with  developing  HLA  applications,  and  the 
project  required  them  to  both  build  new  native  HLA 
interfaces  for  their  applications  and  to  participate  in  the 
design  and  development  of  a  new  federation.  The 
schedule  is  depicted  in  Figure  3. 


1.8  Products  and  Deliverables 

The  planned  products  and  deliverables  for  the  Tasmanian 
Devil  project  were: 

•  HLA  interfaces  for  all  federates  using  RTI  1.3NG3 

•  Taz  FOM  and  SOMs  in  Object  Model  Library4 

•  Taz-AF  and  TazNav  federation  demonstrations 

•  HLA  compliance  certification  for  all  federates 

•  Training  domain  checklist 

•  Lessons  learned  document 

•  Plan  for  future  industry  and  other  service 
participation 

•  Plan  for  future  distributed  Taz-joint  federation 
demonstration 

2.  FEDEP  Highlights 

While  FEDEP  execution  products  or  results  are  presented 
here  in  step  order,  it  is  important  to  note  that  the  FEDEP 
was  not  executed  in  lock  step  order  nor  once-through. 
Rather,  as  each  FEDEP  step  was  performed  and  new 
information  was  discovered,  previous  steps  would  be  re¬ 
visited,  as  needed,  in  order  to  ensure  product 
completeness.  Please  also  note  that  only  the  first  five 
FEDEP  steps  were  executed  due  to  schedule  constraints. 

2.1  Step  1:  Define  Federation  Objectives 

A  federation  purpose,  a  scenario,  training  objectives, 
tasks,  measures  of  effectiveness  (MOEs),  and  schedule 
drivers  were  identified. 


2  VTC’s  hlaResults™  tool  was  successfully  integrated 
into  Taz-Nav  but  was  not  demonstrated  due  to  unresolved 
network  problems.  The  tool  will  be  demonstrated  with 
both  Taz-AF  and  Taz-Nav  in  Taz-2000. 


3  ASTi  self-funded  development  of  their  HLA  interface 
and  therefore  it  was  not  a  deliverable  to  the  government 

4  To  protect  the  information,  a  point  of  contact,  rather 
than  the  actual  SOMs,  is  provided  for  the  AFRL  SOMs. 


2.1.1  Purpose 

The  purpose  of  the  Tasmanian  Devil  federations  is  to 
provide  Air  Force  and  Navy  high  fidelity,  warfighter- in- 
the-loop,  mission-level  training  for  a  specific  set  of  air-to- 
air  tasks. 

The  design  perspective  used  was  that  the  federations  are 
the  starting  point  for  a  persistent  and  evolutionary 
federation  capability  that  will  support  the  full  range  of 
joint  air  combat  missions  and  platforms. 

2.1.2  Scenario 

ACC  defined  the  basic  scenario,  which  was  refined  by 
subject  matter  experts  at  AFRL.  The  scenario  is  depicted 
in  Figure  4. 

2.1.3  Training  Objectives,  Tasks  and  MOEs 

The  training  staff  at  AFRL  developed  the  training 
objectives,  tasks  and  MOEs.  The  training  objective  for 
the  federation  is  to  develop  pilot  proficiency  in 
performing  Defensive  Counter  Air  (DC A)  procedures. 
The  specific  mission  tasks  that  the  pilots  must  perform  to 
demonstrate  proficiency  in  DC  A  procedures,  and  that  the 
federation  must  therefore  support,  are: 

•  Maintain  situational  awareness. 

•  Maintain  radio  discipline. 

•  Perform  CAP  management. 

•  Perform  missile  management. 

•  Perform  sensor  management. 

•  Perform  threat  suppression. 

Mission-  and  task-level  MOEs  that  could  be  collected  to 
verify  that  the  training  objectives  are  met  were  identified 
and  include  both  subjective  measures  assessed  by  the 
training  staff  and  objective  measures  that  could  be 
computed  from  collected  federation  data.  The  latter  type 
of  MOEs  include: 

•  RED  aircraft  penetration  across  Commit  and 
Vulnerability  Lines, 

•  Trainee  accuracy  (BLUE  fires  versus  RED  kills), 

•  RED  kills  by  trainee,  and 

•  Trainee  mission  survivability  (did  the  trainee  survive 
the  mission). 

2.1.4  Schedule  Drivers 

Schedule  drivers  were  identified  as: 

•  Completion  date  by  3 1  December 

•  Availability  of  beta  version  of  VxWorks  RTI 


•  Availability  of  simulators  -  both  AFRL  and 
ACETEF  MFS  maintain  busy  lab  schedules  and, 
additionally,  AFRL  planned  to  ship  out  their 
simulators  for  the  Air  Force  Association  Conference 
in  September  and  I/ITSEC  in  December. 

•  Availability  of  Ordnance  Server  federate  -  ACETEF 
MFS  developed  a  new,  C++-based  ordnance  server  in 
parallel  to  this  effort. 

•  Availability  of  DCS  -  AFRL  developed  this 
completely  new  controller  station  in  parallel  to  the 
Tasmanian  Devil  effort. 

To  mitigate  the  risk  associated  with  these  schedule 
drivers,  the  team  agreed  to  constrain  the  complexity  of  the 
implementation. 

2.2  Step  2:  Develop  Federation  Conceptual  Model 

There  were  three  elements  to  this  step.  First  the 
conceptual  model  of  the  key  events  and  objects  in  the 
virtual  battlespace  required  to  meet  specific  training 
requirements  was  defined  based  on  the  scenario  defined 
in  Step  1 . 

Next,  training  requirements  were  identified.  These 
requirements  are  that  the  trainer/evaluator  be  able  to: 

•  observe  the  training  audience,  both  in  real-time  and 
in  playback  mode. 

•  collect  data  required  to  compute  MOEs  and  MOPs 

•  set  initial  conditions 

•  alter  course  of  events  /  inject  events 

Finally,  technical  requirements  were  identified.  These 
requirements  are  that  the  technical  federation  manager  be 
able  to: 

•  monitor  federation  health 

•  schedule  saves  and  restores 

•  coordinate  federation  synchronizations 

•  measure  federation  technical  performance  (e.g., 
network  bandwidth  usage,  federate  computational 
workload,  etc.) 

•  control  federates  (e.g.,  “SIMAN”-like  functions  such 
as  pause  and  resume,  turn  logging  on  and  off,  change 
simulation  time,  etc) 

2.3  Step  3:  Design  Federation 

This  step  involved  allocation  of  conceptual  model 
functionality  to  federates,  and  the  design  of  features  to 
meet  the  training  and  technical  requirements. 


2.3.1  Allocation  of  Conceptual  Model  Functionality 
to  Federates 


2.3.2  Trainer  Requirements  and  Possible  Design 
Solutions 


The  allocation  of  conceptual  model  functionality  to 
federates  is  depicted  in  Table  1. 


Table  1.  Allocation  of  Conceptual  Model 
_ Functionality  to  Federates _ 


Functionality 

Federate 

Blue  (AF)  F-16  aircraft  and 

Blue  AA  missiles 

AFRL  simulators 

Blue  (Navy)  F-18  aircraft 

ACETEF  MFS 
simulators 

Blue  (Navy)  AA  missiles 

ACETEF  MFS 
ordnance  server 

Red  aircraft,  Red  AA  missiles, 
Red  SAM  sites,  Red  C2 
ground  sites  ,  and  SA  missiles 

JSAF 

Blue  CAP  (AF  and  Navy) 
aircraft  and  Blue  Control 
(AWACS)  aircraft  radio  sets 

ASTi  radio 
simulation 

The  design  alternatives  identified  by  the  team  to  meet 
trainer  requirements  are  presented  in  Table  2.  Due  to 
schedule  and  budget  constraints,  many  design  solutions 
were  not  completely  implemented.  Alternatives  in  normal 
font  were  implemented,  those  in  bold  were  partially 
implemented,  and  those  in  italics  were  not  implemented. 

2.3.3  Technical  Requirements  and  Possible  Design 
Solutions 

The  design  alternatives  identified  by  the  team  to  meet 
technical  requirements  are  presented  in  Table  3.  Due  to 
schedule  and  budget  constraints,  many  design  solutions 
were  not  completely  implemented.  Alternatives  in  normal 
font  were  implemented,  those  in  bold  were  partially 
implemented,  and  those  in  italics  were  not  implemented. 


Table  2.  Possible  Design  Solutions  for  Trainer 
_ Requirements _ 


Trainer 

Requirement 

Design  Alternative 

Generate  MOEs  and 
MOPs 

•  Extend  FOM 

•  Observe  from  “god’s  eye” 
perspective 

•  Playback  plan- view  display 

•  Playback  video  tapes  of 
cockpit  HUDs 

•  Playback  cockpit  HUD  video 
tapes 

•  Interview  pilots 

Set  initial  conditions 
(e.g.,  fuel,  location, 
speed,  etc.) 

•  Extend  FOM 

Alter/inject  events 

•  Blue  controller  give  verbal 
“hints”,  misinformation,  etc 

•  Extend  FOM 

Table  3.  Possible  Design  Solutions  for  Technical 
_ Requirements _ 


Technical 

Requirement 

Design  Alternative 

Monitor  and 
control  RTI  state 

•  MOM  data  /  FMT 

Monitor  and 
control  federates 

•  Talk  to  federate  operators 

•  FOM  extensions 

Measure 

federation 

technical 

performance 

•  MOM  data 

•  Performance  instrumentation  of 
federates  and  FOM  extensions 

2.4  Step  4:  Develop  Federation 


This  step  involves  the  creation  of  the  FOM  and  creation 
or  adaptation  of  the  federation’s  federates.  The  Taz  FOM 
was  developed  via  the  approach  depicted  in  Figure  5.  The 
team  focused  first  on  the  conceptual  model,  and  training 
and  technical  requirements  from  the  previous  phases. 
Then,  the  team  reviewed  each  federate’s  SOM.  From 
these  inputs,  along  with  the  technical  and  legacy 
constraints  and  design  principles,  the  team  drafted  the 
first  FOM  from  which  to  build  consensus.  The  team 
iterated  through  a  series  of  drafts  as  conceptual  and 
requirement  topics  were  addressed,  thus  building  a 
finished  FOM. 

FOM  design  principles  designed  to  take  full  advantage  of 
the  HLA  services  and  to  support  automation  were 
developed  and  followed.  These  principles  included: 


•  Execute  a  phased  approach  for  building  the  FOM  - 
First  the  Conceptual  Model  (warfighter  issues)  was 
used  to  draft  a  FOM.  Then,  trainer  requirements  and 
technical  requirements  were  added  in  stages.  Finally, 
federation  execution  items  were  plugged  in. 

•  Define  class  hierarchies  for  easy  future  expansion  - 
Potential  future  object  and  interaction  classes  were 
considered  so  that  the  hierarchy  could  be  defined  to 
allow  for  new  sub-classes  to  be  added  without 
affecting  existing  classes  or  federates. 

•  Promote  general  attributes,  especially  identification 
enumerations,  to  highest  levels  -  General  attributes 
were  promoted  to  allow  general-purpose  viewer 
federates  to  subscribe  to  highest  levels,  thus  greatly 
reducing  (if  not  eliminating)  impact  of  future 
hierarchy  expansion. 

•  Group  attributes  and  parameters  based  on  need  for 
consistency  -  Attributes  and  parameters  were 
grouped  as  complex  data  types  to  ensure  object 
temporal  consistency,  as  well  as  to  improve  general 
data  handling.  At  same  time,  the  benefit  of  grouping 
was  weighted  against  the  limitations  it  places  on 
object  ownership  (the  whole  group  must  be 
transferred)  and  the  impacts  on  data  throughput 
efficiency  (the  whole  group  must  be  published). 

•  Use  other  related  FOMs  as  a  starting  point  -  The 
RPR-FOM  was  used  for  Taz  as  a  start,  particularly 
for  content.  Changes,  additions,  and  deletions  were 
made  to  support  specific  Taz  requirements,  and  to 
adhere  to  these  FOM  design  principles. 

•  Consider  modeling  “one-time”  events  in  the 
receiving  federate  -  One  time  events  could  be 
handled  by  having  the  event-initiator  send  and 
interaction  to  initiate  receiver  side  modeling  of  the 
event.  This  design  would  allow  significant  reduction 
in  bandwidth,  but  might  shift  the  burden  for 
modeling  to  federates  not  designed  to  support  it, 
might  frustrate  “fair-fight”  requirements. 

•  Define  all  enumeration  values  in  FOM  -  All 
enumeration  values  were  put  in  the  FOM  to  provide  a 
single  place  for  documenting  enumerations,  and  to 
allow  automated  tools  to  key  off  the  FOM  directly. 

•  Define  data  formats  in  FOM  -  Data  formats  were 
fully  defined  in  the  FOM  (without  use  of  “any”  type), 
to  allow  automated  tools  and  code  generators  to  work 
from  directly  from  FOM. 

•  Maintain  array  counts  explicitly  -  Array  counts  were 
explicitly  put  in  the  FOM  to  facilitate  automated  tool 
execution  and  reduce  receiver  side  processing. 

In  parallel,  the  team  defined  the  federation  policies  and 
documented  them  in  the  Federation  Agreements  and 
Implementation  Document,  or  FAID.  The  FAID  is  shown 
as  a  product  of  the  FOM  development  process  in  Figure  5 
and  its  contents  are  described  in  Figure  6. 


Figure  5.  Tasmanian  Devil  FOM  Design  Process 
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Figure  6.  FAID  Table  of  Contents 


Once  the  FOM  was  completed,  the  next  activity  was  to 
build  the  HLA  interfaces.  Both  AFRL  and  ACETEF 
MFS  adopted  interface  approaches  that  would  allow 
maximum  reuse  across  the  different  federates  that  they 
own.  New  interfaces  were  built  for: 

•  AFRL  F- 1 6  simulator 

•  AFRL  controller  station 

•  ACETEF  MFS  F- 1 8  simulator 

•  ACETEF  MFS  ordnance  server 

•  ASTi  Radio 


JSAF  has  an  agile  FOM  interface  that  includes  many 
predefined  mappings  of  the  JSAF  SOM  to  alternate 
FOMs.  For  this  project,  the  JSAF  developer  selected  the 
appropriate  mapping  to  the  Taz  FOM,  or  in  the  cases 
where  a  predefined  map  did  not  exist,  created  one. 


Terrain  databases  were  identified  and  reused  for  the 
cockpit  simulator  image  generators  and  JSAF.  Based  on 
the  project  scenario,  a  database  containing  the  appropriate 
forces  and  scripts  was  developed  for  JSAF. 

Finally,  an  important  product  of  the  federation  design  was 
an  evolution,  or  “later”  list,  capturing  all  the  functionality 
not  implemented  in  the  interest  of  schedule.  This 
includes: 

•  Alter/inject  training  events 

•  Full  MOE  and  MOP  production,  potentially 
including  cockpit  data 

•  Robust  and  reusable  set  initial  condition  interactions 

•  Full  federate  control  interactions 

•  Measure  federation  technical  performance 

•  Functional  enhancements 

•  Visual  and  environment  factors 

•  Aircraft  datalinks 

•  IFF 

•  Articulated  parts  for  entity  representations 

•  Chaff,  flare  and  ECM  effects  modeling 

•  Multi-spectral  sensor  capabilities  (EO,  IR,  laser) 

•  Collisions 

2.5  Step  5:  Integrate  and  Test  Federation 


Pre-integration  tests  of  each  federate  in  a  stand-alone 
mode  and  three  full  federation  integration  events  for  each 
laboratory  were  planned.  Pre-event  readiness  reviews 
resulted  in  some  dates  changes  but  schedule  flexibility 
was  limited  by  simulator  availability 

A  lesson  learned  was  that  the  simulators  were  not 
required  at  early  events  and  that  simulator  surrogates  are 
better  suited  for  early  integration  activities. 

A  benefit  of  developing  parallel  federations  was  that 
alternating  events  between  labs  allowed  for  lessons 
learned  at  one  event  to  be  applied  at  the  next.  As  a  result, 
each  laboratory  was  able  to  piggyback  on  the  progress  of 
the  other. 

The  F-16  simulators  and  DCS  at  AFRL  completed  HLA 
compliance  testing.  Compliance  testing  could  not  be 
scheduled  at  ACETEF  MFS  due  to  conflicting  schedules 
for  simulator  availability  at  ACETEF  MFS  and  the 
compliance  testing  team,  but  that  testing  will  be 
scheduled  at  the  earliest  available  date. 

However,  total  integration  was  not  completed  at  either 
laboratory.  The  demonstrations  were  conducted  as 
scheduled  but  neither  Taz-Nav  nor  Taz-AF  were  as  robust 
as  the  team  would  have  preferred  and  there  were 
anomalies  in  both  federations  that  remain  uninvestigated 
as  of  the  writing  of  this  paper. 

3.  Major  Findings 

The  following  findings  are  preliminary.  A  more  complete 
assessment  will  follow  completion  of  integration  of  Taz- 
AF  and  Taz-Nav. 

3.1  HLA 

Use  of  the  HLA  has  been  successfully  demonstrated  in  a 
high  fidelity,  warfighter-in-the-loop  air-to-air  training 
environment.  The  project  served  as  a  beta-site  for  RTI- 
NG,  which  was  just  officially  released  in  November 
1999.  AFRL  made  first  use  of  the  VxWorks  version  of 
the  RTI.  Both  AFRL  and  ACETEF  MFS  demonstrated 
use  of  RTI-NG  in  a  federation  that  included  federates 
using  other  operating  systems  (i.e.,  Windows  NT,  Linux, 
and  VxWorks). 

RTI-NG,  the  FEDEP,  and  the  supporting  tools  were  all 
useful,  but  the  team  is  in  the  process  of  documenting 
specific  areas  where  improvements  are  needed. 

Still  to  be  completed  is  final  development,  integration, 
tuning  and  assessment  of  the  federations. 


3.2  FOM 

A  single  FOM  can  support  different  services  and  different 
federates. 

The  aircrew  distributed  mission  training  community 
needs  to  define  its  own,  single  objective  FOM.  This  FOM 
would  support  the  community’s  persistent  federation, 
which  will  consist  of  those  simulators  that  will  be 
routinely  used  and  reused  in  different  combinations  to 
support  distributed  mission  training.  Having  an  objective 
FOM  would  support  “plug  and  play”  operations  within 
the  community.  The  FOM  should  be  developed,  tested, 
optimized  and  evolved  for  this  community  by  the 
community  stakeholders,  and  should  provide  a  push  for 
the  establishment  of  industry  standards. 

An  objective  FOM  in  this  domain  should  support  not  only 
the  conceptual  model,  but  should  also  support  trainer  and 
technical  requirements.  This  would  facilitate  adoption  of 
an  integrated  training  and  technical  management 
approach  across  the  community  and  further  promote 
interoperation. 

Non-persistent  FOM  subsets  can  be  added  temporarily  to 
an  objective  FOM  for  a  particular  federation  execution(s) 
to  meet  non-general  federate  or  facility  requirements.  For 
example,  the  Taz  FOM  included  non-persistent  FOM  add¬ 
ons  to  support  the  JSAF  simulation  control  SOM,  the 
VTC  hlaResults™  SOM,  and  technical  control  functions 
at  AFRL  that  were  implemented  in  a  custom  fashion. 

Objective  FOM  design  decisions  need  to  include  not  only 
near  term  cost  considerations,  but  also  life-cycle  cost.  A 
design  that  is  best  for  legacy  federates  may  not  be  the  best 
design  for  future  evolution.  Additional  consideration 
should  be  given  to  overall  federation  performance.  Sound 
FOM  design  practices  are  needed  to  make  full  use  of  the 
HLA  RTI  services  and  supporting  tools. 

The  Real  Time  Reference  (RPR)  FOM  is  a  good  starting 
point  for  objective  FOM  content  that  addresses  the 
requirements  of  the  conceptual  model.  However, 
improved  data  content,  organization,  and  structure  are 
required  to  make  full  use  of  the  capabilities  of  the  HLA. 
In  addition,  the  content  needs  to  be  expanded  to  include 
additional  battlespace  elements  such  as  the  natural 
environment  and  C4I,  and  the  data  exchanges  to  meet 
trainer  and  technical  requirements. 

Finally,  it  must  be  noted  that  the  same  arguments  for 
having  an  optimized  domain-specific  objective  FOM 
apply  in  other  domains.  There  will  likely  be  occasional 
requirements  for  federates  from  this  domain  to 


interoperate  in  federations  using  a  different  FOM  and,  in 
those  cases,  an  agile  FOM  interface  can  significantly 
reduce  the  costs  of  integration. 

3.3  FEDEP 

The  FEDEP  is  well  suited  for  the  development  of  new 
federations  from  start  to  finish.  However,  a  persistent 
federation  is  sufficiently  different  that  a  separate  process 
altogether  may  be  warranted  to  describe  its  development 
and  execution.  Important  differences  include  the 
following: 

•  The  life  cycle  of  a  persistent  federation  has  two 
distinct  phases.  The  first  phase  will  define  the  overall 
objectives,  conceptual  model,  trainer  and  technical 
requirements,  and  FOM  for  the  persistent  federation 
as  whole. 

•  This  phase  will  likely  also  include  significant  testing 
of  the  objective  FOM  and  individual  federate  ability 
to  interoperate  using  the  FOM. 

•  This  phase  will  be  relatively  time-consuming  and 
should  be  executed  with  attention  to  the  long  term 
benefits  of  general  and  flexible  design. 

•  This  phase  will  be  executed  once,  or  in  the  case  of  an 
evolutionary  federation,  will  be  executed  iteratively 
in  a  managed  fashion  to  meet  new  requirements. 

•  The  second  phase  will  be  in  a  steady-state  mode 
focused  on  plug  and  play  operations.  In  steady  state, 
the  conceptual  modeling/  requirements  definition 
step  will  simplify  to  selection  from  a  predefined 
shopping  list  of  capabilities  defined  by  the  persistent 
federation’s  conceptual  model,  trainer,  and  technical 
requirements. 

•  Similarly,  in  steady  state,  the  design  step  will 
simplify  to  allocation  of  functionality  to  federates. 

•  The  develop  step  will  simplify  to  building  of 
databases  and  “plugging-in”  of  federates  that  are 
ready  to  operate  with  the  objective  FOM 

•  The  test  step  will  focus  on  system  checkout,  rather 
than  integration  of  new  software. 

3.4  Schedule 

More  time  should  have  been  allocated  to  this  project,  or 
else  the  first  two  FEDEP  steps  (Define  Objectives  and 
Develop  Conceptual  Model)  should  have  been  completed 
prior  to  project  start.  The  team  make-up  was  primarily 
technical  personnel  and  did  not  include  the  right  kind  of 
expertise  to  perform  the  first  two  steps  without  seeking 
(belatedly)  outside  help.  This  lesson  should  be  applied  to 
team  composition  for  future  distributed  mission 
community  FOM  development  work. 

Another  factor  that  impeded  progress  was  the  difficulty  in 
scheduling  simulator  test  time.  A  single  small  schedule 


slip  can  result  in  long  overall  delays  if  the  simulators  are 
not  available  when  needed.  A  method  to  alleviate  this 
problem  is  to  test  the  FOM  thoroughly  in  a  purely 
software  environment  before  testing  it  in  the  cockpits. 

3.5  Findings  Under  Construction... 

As  of  the  writing  of  this  paper,  a  follow-on  to  the 
Tasmanian  Devil  project  is  planned.  The  current  plan  is 
for  Tasmanian  Devil  2000  to  complete  integration,  and 
tune  the  federation.  Tasmanian  Devil  2000  will  also  allow 
the  team  to  study  and  reflect  on  the  entire  process,  and  to 
fully  capture  lessons  learned.  Among  some  of  the  areas  to 
be  addressed  are  objective  FOM  design  balance, 
federation  assessment,  and  the  use  and  definition  of  FOM 
agility  in  a  persistent  federation  environment. 
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Overview 

*  Background  and  Definitions 

*  Research  Approach  and  Schedule 

*  Scenario  and  Federation  Overview 

*  FOM  Design  Process  and  Philosophies 

*  Findings 

-FOM 
- FEDEP 
-Tools 
-Testing 

*  Summary 
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Background 


*  DMSO  developed  the  High  Level  Architecture  (HLA) 
and  supporting  tools,  software  and  processes  to 
support  the  broad  DoD  M&S  community 

*  The  Air  Force  is  interested  to  use  the  HLA  to  meet  its 
future  distributed  mission  training  requirements 

*  The  Air  Force  and  the  Navy  are  interested  in  how  the 
HLA  can  help  support  joint  training 

*  Tasmanian  Devil  is  a  research  project  aimed  at 
gaining  practical  experience  in  the  application  of  the 
HLA  in  the  distributed  mission  training  domain 


Tasmanian  Devil  (Taz)  research  federations  are  to  provide  Air  Force 
and  Navy  high  fidelity,  warfighter-in-the-loop,  mission-level  training 

for  a  specific  set  of  air-to-air  tasks. 
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Definitions 


*  Persistent  federation:  a  collection  of  specific 
federates  and  objective  FOM  used  by  those  federates. 

-  “Persistent”  due  to  use/reuse  over  an  extended  period  of  time. 

-  Any  logical  subset  of  the  federates  and  FOM  may  be  used. 

*  Evolutionary  federation:  a  persistent  federation  that 
evolves  its  composition  (FOM  &  federates)  over  time. 

-  Evolution  must  be  systematically  managed  to  ensure 
configuration  control  and  reduce  adverse  impact  from  change 

*  Objective  FOM:  describes  all  data  that  might  be 
exchanged  at  runtime  within  a  persistent  federation. 

*  FOM  Agility:  federate  ability  to  “easily”  map  its  SOM 
to  the  FOM  of  a  particular  federation  execution. 

Federations  supporting  the  distributed  mission  training  domain  will 
likely  be  / persistent  and  evolutionary,  perhaps  using  FOM  agility 


Research  Approach 
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Taz  Schedule 
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Step  1:  Def  Federation  Objectives 

Step  2:  Develop  Federation 
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Scenario  Overview 


Mission:  Protect  friendly  airspace  against  threat  penetration  while 
minimizing  own  casualties 
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Team  Members,  Federates  and 

Federations 


AFRL/HEA  (Mesa,  AZ) 

-  2  USAF  F-16  simulators 

-  Director  controller  station 

Manned  Flight  Simulator 
(Pax  River,  MD) 

-  2  USN  F-18  simulators 

-  Ordnance  server 
LMIS 

-  JSAF  Combat  Simulation 
ASTI 

-  Radio  System  Simulation 
DMSO  &  DMSO  Cadre 

-  System  Engineering  Support 

-  Various  DMSO  Tools  &  RTI 
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Tasmanian  Devil  FOM 
Design  Process 


4^)Potential  persistent  FOM 
9  Execution  specific  add-on 


1st  Pass  -  CM 
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FOM  Design  Philosophies 


*  Execute  a  phased  approach  for  building  the  FOM 

*  Define  class  hierarchies  for  easy  future  expansion 

*  Promote  general  attributes,  e.g.  identification 
enumeration,  top  highest  levels 

*  Group  attributes  and  parameters  based  on  need  for 
temporal  consistency 

*  Use  other  related  FOMs  as  starting  point 

*  Consider  modeling  “one  time”  events  in  receiving 
federate 

*  Define  all  enumeration  values  in  FOM 

*  Define  data  formats  in  FOM 

*  Maintain  array  counts  explicitly 
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Federation  Agreements  / 
Implementation  Document  (FAID) 

*  Describes  Federation  in  more  detail  than  FOM 

-  More  semantic  meaning  to  data  flowing  between  federates 

-  Companion  /  addendum  to  FOM 


Table  of  Contents 

•  Objectives 

•  Conceptual  Model  and 
Requirements 

•  Federation  Agreements 

•  Data  Collection  Plans 

•  FOM  Details 

•  Classes  and  Interactions 

•  Attributes  and  Parameters 

•  Complex  Datatypes 

•  Simple  Datatypes 

•  Evolution  List 


Agreements 
Time  management 
approach 

Chaff/flare  operations 
Dead  reckoning 
Collision  calculations 
Attrition  calculations 
Sensor  modeling 
Low  level  data 
formatting 
Coordinate  systems 
•  Ordnance  server  handoff 
Federate  ID  approach 
Synchronization  pomtsr 
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Major  Findings  -  FOM 


*  A  single  FOM  can  support  different  services  and 
different  federates 

*  The  aircrew  distributed  mission  training  community 
needs  to  define  its  own  objective  FOM 

-  supporting  the  community’s  persistent  /  plug&play  federation 

-  optimized  for  and  evolved  by  this  community 

*  Design  decisions  need  to  include  near  term  and  life- 
cycle  cost  and  performance  considerations 

-  Sound  design  practices  to  make  use  of  HLA  RTI  services  and 
supporting  tools,  as  needed 

-  Trade  off  legacy  federates  needs  vs.  future  evolution 

*  FOM  subsets  (persistent  or  not)  added  for  particular 
federation/federate  needs  or  execution  goals 


-to  meet  requirements  of  particular  f 


d/or  facilities 
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Major  Findings  -  FOM 


*  Technique  for  abstracting  or  filtering  view  of  FOM 
would  be  useful 

-  Often  hard  to  follow  /  find  things  when  FOM  is  cluttered  with 
extra,  federate  specific  class  and  interactions 

-  FOM  tools  should  consider  some  type  of  mechanism  to  allow 
for  filtered  views  of  FOM 

*  Even  with  an  objective  FOM,  there  will  likely  be  need 
for  FOM  agile  interface  techniques 

-  Reduce  costs  of  integration  into  a  test  or  exercise  federation 

-  Can  help  reduce  impacts  of  FOM  evolution 

*  Taz  FOM  entity  identification  approach 

-  We  used  new,  structure-independent  enumeration  in  order  to 
include  directly  in  FOM 

-  Codifying  DIS  enumeration  might  have  been  possible,  but... 


2000  Spring  Simulation 
Interoperability  Workshop 


Major  Findings  -  FEDEP 

*  Checklist  for  persistent  federations  would  be  useful 

-  Gives  impression  that  a  new  FOM  must  be  developed  for  each 
federation  execution 

-  FEDEP  does  allow  that  FOM  development  may  simply  mean 
using  an  existing  FOM 

*  FEDEP  activities  under-scoped  in  project  schedule 

-  Of  7  month  schedule,  first  2  months  spent  defining  objectives 
and  conceptual  model,  and  in  mutual  discovery 

*  FAID  critical  to  conveying  expected  interoperations 

-  But,  must  be  agreed  to  and  understood 

-  No  substitute  for  continual  dialogue 

*  Trainer/technical  requirements  must  be  addressed 

-  Need  to  identify  these  requirements  and  facilitate  them 
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Major  Findings  -  Tools 

•  RTI  NG  (used  beta  and  first  release) 

-  Successful  with  RTI  NG  on  VxWorks  platform  (along  with 
mixed  other  operating  systems 

-  RTI  NG  memory  requirements  on  VxWorks  platform  are  high 

•  OMDT 

-  A  real  workhorse,  but  user  interface  awkward  at  times 

•  Visual  OMT 

-  Better  user  interface,  but  has  its  own  limitations 

•  FEPW  (used  early  beta  versions) 

-  FOM  updates  required  data  to  be  re-entered 

-  Enumerated  datatypes  size  information  not  included  in  FOM 
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Major  Findings  -  Tools 

*  FMT  (used  multiple  beta  versions) 

-  Some  difficulty  with  installations  and  execution 

-  Very  useful  tool  during  early  phases  of  integration,  gave  great 
insight  into  what  federates  were  doing 

*  Test  Federate 

-  Invaluable  early  in  integration 

-  Better  interface  and  operations  are  required 

*  DCT  /  hlaResults 

-  Captures  object  updates  and  interactions  for  integration  tests 

-  Invaluable  in  gaining  insights  into  federation  MOE  data 

-  Replay  capability  developed  and  demonstrated  in  lab 

DMSO  Tools  helped  the  project  be  successful, 
while  also  showing  what  to  look  for  “off  the  shelf”. 
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Major  Findings  -  HLA  Testing 

*  HLA  compliance  testing  value 

-  Passed  tests  with  little  of  planned  functionality  operational 

-  Hard  to  explain  compliance  tests  meaning  to  management 

-  Passing  tests  says  more  about  ability  to  create  HLA  federates 
than  about  functionality  (or  anything  about  interoperability) 
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Results,  Conclusions, ... 

*  Use  of  the  HLA  has  been  successfully  demonstrated 

-  First  step  for  distributed  mission  training  environments 

-  RTI  NG  under  VxWorks  and  with  mixed  operating  systems 

-  But  still  some  tuning  and  assessments  to  be  done 

*  HLA  RTI  NG,  FEDEP  processes  and  supporting  tools 
were  all  useful,  with  some  suggested  improvements 

-  Need  to  better  address  needs  of  persistent  federations 

*  Next  Phases  of  Tasmanian  Devil  will  address 
federation  stability  and  performance  issues 

-  FOM  changes  in  work 

-  Demonstrations  planned  for  Summer  2000 

-  Detailed  “interim”  report  in  work 
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